All DatabasesMacTech Vol 12-1996
AS vs Frontier
Volume Number: 12
Issue Number: 1
Column Tag: Internet Development
CGI’s: AppleScript or Frontier?
Comparing scripting environments for CGI development
By Mason Hale
Note: Source code files accompanying article are located on MacTech CD-ROM or
source code disks.
In a previous article, “Scripting the Web with Frontier”, I introduced you to writing
CGI scripts using UserLand Frontier. In that article, I argued that Frontier was an
excellent alternative for webmasters who felt forced to choose between the poor
performance of AppleScript and the steep learning curve of C because Frontier is
easier to use than C yet generally performs faster than AppleScript, especially when
used to create CGI applications. That argument became even more true when a
PowerPC-native Frontier was released for public beta-testing in late October. Like
dropping a bigger engine into a hot rod, script execution instantly becomes much faster
- in some cases up to six time faster. With this boost in speed on PowerPC machines,
Frontier is closing the gap on C - offering both ease-of-use and excellent performance
- while further increasing its lead on AppleScript.
Despite the proven benefits of using Frontier to write CGI applications, many
webmasters still are developing their CGIs in AppleScript. This inspired me to look a
bit more closely at the differences between CGI applications written in Frontier and
those in AppleScript, primarily focusing on performance issues. In this article I will
share the results of some of my recreational performance testing, and explain some of
the different situations that affect performance.
Since I am the author of the Frontier CGI Framework, a set of scripts that
enhance CGI development in Frontier, you could understandably question my
objectivity in doing such a comparison. On the other hand, since I have done a great deal
of CGI development in both environments, I am also one of the few people qualified to do
such a comparison. In either case it is not my intent to discount AppleScript as a
scripting environment. I think it is a great product and an important technology. I just
don’t believe it is well-suited to the specific task of CGI development.
Performance
Performance is crucial to CGI applications running on busy servers. The more
processing time a request takes, the more likely a user is to give up and move on to
another site.
I’ve often been asked if Frontier is faster than AppleScript. The truth is, when
comparing built-in verbs in AppleScript and the non-native version of Frontier, the
performance is surprising similar. I ran a series of informal tests to compare the
performance of AppleScript, non-native Frontier and native Frontier when running
equivalent scripts. The scripts are based on the sample scripts from Frontier’s object
database. All tests were run on a Power Macintosh 7200/75 with 16 MB RAM.
Execution time is measured in ticks (sixtieths of seconds).
The first test script performs simple integer arithmetic using built-in
commands in both the AppleScript and UserTalk versions. The actual scripts are
functionally identical.
Test 1: Integer Arithmetic (AppleScript)
set x to 0
repeat with i from 1 to 1000
set x to x + (12 + 99 - 37 / 84)
end
Test 1: Integer Arithmetic (UserTalk)
x = 0
for i = 1 to 1000
x = x + (12 + 99 - 37 / 84)
AppleScript took 111 ticks to complete the first test, while the non-native
Frontier took 103 ticks. The PowerPC-native Frontier ran the same script in just 17
ticks. This first test really shows how close the non-native Frontier and AppleScript
were - and the tremendous difference the native version makes.
The second test demonstrates the repeated calling of a local subroutine.
Test 2: Subroutine Call (AppleScript)
set y to 10
on moof (x)
return (x * 2)
end
repeat with i from 1 to 1000
set y to moof (y)
end
Test 2: Subroutine Call (UserTalk)
y = 10
on moof (x)
return (x * 2)
for i = 1 to 1000
y = moof (y)
AppleScript blew the doors of the non-native Frontier in the second test coming
in at 85 ticks to Frontier’s 272 ticks. However, the PowerPC-native Frontier handily
won with a time of 47 ticks.
The third script compares the performance of commands from an external
Scripting Addition to a built-in Frontier verb. I compared the speed of Frontier’s
built-in clock.now verb to the equivalent current date Scripting Addition.
Test 3: Built-in verb vs. Scripting Addition (UserTalk)
for i = 1 to 100
y = clock.now ()
Test 3: Built-in verb vs. Scripting Addition (AppleScript)
repeat with i from 1 to 100
set y to current date
end repeat
It took AppleScript 113 ticks to complete this test, while the non-native
Frontier took 17 ticks and the native Frontier took 5 ticks. This illustrates a crucial
point in determining the speed of a script. Built-in commands are faster than
commands loaded from external code fragments. Because AppleScript has few built-in
verbs and relies heavily on Scripting Additions to extend the language, the use of
external commands like “current date” is quite common.
In the fourth example the script checks the existence of a file. Frontier uses a
built-in verb “file.exists”, while AppleScript communicates with the scriptable
Finder via AppleEvents.
Test 4: Built-in verb vs. Apple Event (AppleScript)
set x to 0
tell application "Finder
repeat with i from 1 to 10
if exists alias "Macintosh HD:SimpleText" then
set x to x + 1
end if
end repeat
end tell
Test 4: Built-in verb vs. Apple Event (UserTalk)
local (x = 0)
for i = 1 to 10
if file.exists ("Macintosh HD:SimpleText")
x++
Inter-application communication can really slow things down. Each
cross-application Apple Event adds approximately 1/4 second to the processing time of
the script. Frontier suffers the same slowdowns when sending Apple Events to other
applications, but because more commands are available, external applications are
relied on less often.
The results of the fourth test bear this out. While the native and non-native
Frontier applications finished in 3 ticks and 7 ticks respectively, AppleScript took
140 ticks to perform the same task using the scriptable Finder.
My final test was “real world” example, based on the “test.cgi” script that is
distributed with MacHTTP. This script uses no scripting additions and doesn’t perform
any cross-application communication. So it is a pretty good example of a common CGI
script using built-in verbs.
Test 5: Test CGI (AppleScript)
property crlf : (ASCII character 13) & (ASCII character 10)
--this builds the normal HTTP header for regular access
property http_10_header : "HTTP/1.0 200 OK" & crlf &
"Server: MacHTTP" & crlf & "MIME-Version: 1.0" &
crlf & "Content-type: text/html" & crlf & crlf
on cgiScript (path_args, http_search_args, username,
password, from_user, client_address, server_name,
server_port, script_name, content_type, referer,
user_agent, action, action_path, post_args, method,
client_ip, full_request)
try --wrap the whole script in an error handler
return http_10_header & "Test CGI" &
"

Test CGI

CGI arguments sent:" &
"
path: " & path_args &
"
search: " & http_search_args &
"
post_args: " & post_args &
"
method: " & method &
"
address: " & client_address &
"
user: " & username &
"
password: " & password &
"
from: " & from_user &
"
server_name: " & server_name &
"
server_port: " & server_port &
"
script_name: " & script_name &
"
referer: " & referer &
"
user agent: " & user_agent &
"
content_type: " & content_type & crlf
on error msg number num
return http_10_header & "Error " & num & ", " & msg
end try
end caller
repeat with i from 1 to 10
cgiScript ("aaa", "bbb", "ccc", "ddd", "eee",
"fff", "ggg", "hhh", "iii", "jjj", "kkk",
"lll", "mmm", "nnn", "ooo", "ppp", "qqq", "rrr")
end repeat
Test 5: Test CGI (UserTalk)
on cgiScript (pathArgs, httpSearchArgs, username,
password, fromUser, clientAddress, serverName,
serverPort, scriptName, contentType, referer,
userAgent, action, actionPath, postArgs, method,
clientIp, fullRequest)
try
return (webServer.httpHeader () +
"Test CGI

Test CGI

" +
"CGI arguments sent:" +
"
path: " + pathArgs +
"
search: " + httpSearchArgs +
"
post_args: " + postArgs +
"
method: " + method +
"
address: " + clientAddress +
"
user: " + username +
"
password: " + password +
"
from: " + fromUser +
"
server_name: " + serverName +
"
server_port: " + serverPort +
"
script_name: " + scriptName +
"
referer: " + referer +
"
user agent: " + userAgent +
"
content_type: " + contentType + cr + lf)
else
return (webServer.httpHeader () + "Error " + tryError)
local (i)
for i = 1 to 10
cgiScript ("aaa", "bbb", "ccc", "ddd", "eee", "fff", "ggg",
"hhh", "iii", "jjj", "kkk", "lll", "mmm", "nnn", "ooo",
"ppp", "qqq", "rrr")
As expected, the AppleScript and non-native version of Frontier performed
similarly. The AppleScript CGI test finished in 69 ticks, beating out Frontier at 74
ticks. Native Frontier won again with 14 ticks. A summary of the timing results for
all tests is shown in Table 1.
AppleScript Frontier 68K Frontier PPC
Integer Arithmetic 111 103 17
Subroutine Call 85 272 45
Built-in vs. OSAX 113 17 5
Built-in vs. AE 140 7 3
Test CGI 69 74 14
Table 1. Comparison of execution times (all times in 1/60 second)
Multi-threading
Beyond straight script execution, another factor can significantly affect the speed
at which a given script runs: multi-threading. In the exponentially-growing world of
the internet, it is common for the average web server to receives thousands of requests
a day. It is also quite likely that two clients will request the exact same file at the
exact same time. If the requested file happens to be your CGI script, it will have to deal
with two concurrent requests.
AppleScript is not multi-threaded, and handles multiple concurrent requests by
placing them into a queue. Unfortunately, AppleScript processes events on a last-in
first-out basis - so the latest event received is the first to be processed. To put it
another way, on a very busy server, the first person to call the CGI may very well be
the last person to receive the results. This can result in every single request timing
out if new requests keep forcing older ones further back in the queue.
Frontier is fully multi-threaded. Every new request spawns a new thread
automatically. This means that incoming event are processed immediately and do not
prevent processing of earlier requests.
A more subtle, but still important performance consideration is the fact that all
Frontier-based CGI’s are hosted by a single application. In the cooperative
multi-tasking Mac OS, applications must cooperatively share processing time. Adding
a new, separate application for each CGI creates more overhead to manage the sharing
of processor time among the competing applications and eventually slows down all the
applications. Consolidating all CGI scripts into Frontier’s object database eliminates
this overhead.
Conclusion
Being PowerPC-native and multi-threaded clearly gives Frontier the performance
advantage over AppleScript. However, even if AppleScript were multi-threaded and
native, its reliance on Scripting Additions and external applications to perform its
functions severely limit performance, and thus limit its usefulness as a development
environment for CGI applications.
URL’s
Native Frontier Public Beta release:
http://www.hotwired.com/ userland/yabbadabba/nativefrontierpublicbe_390.html
Frontier CGI Scripting: http://www.webedge.com/frontier/
Aretha Website: http://www.hotwired.com/userland/aretha/
Referenced by (6):